「AWSクラウドデザインパターン for Enterprise」 by 玉川 憲氏 & 片山 暁雄氏 #jawsdays – JAWS DAYS 2014 参加レポート Vol.05

JAWS DAYS 2014 参加レポート、5発目はアマゾンデータサービスジャパン株式会社の、というよりはNinja of Threeの、玉川氏と片山氏によるセッション「AWSクラウドデザインパターン for Enterprise」です。最近AWS界隈ではエンタープライズという単語をよく聞くようになってきましたが、クラウドデザインパターンもそのムーブメントに併せて拡張されていくのでしょうね。

「AWSクラウドデザインパターン for Enterprise」 by 玉川 憲氏 & 片山 暁雄氏

本セッションも立ち見がいっぱい居るくらい人気がありました。その理由はお二人のキャラにもあるのかも知れません:)

本セッションのスライドはこちらです。

はじめに

AWSソリューションアーキテクトであるお二人は最近エンタープライズな分野でのAWS利用についてお客様からお問合せを受けることが多いとのことで、以下の4つの分類について、エンタープライズ用途でも使えるクラウドデザインパターンを考えられたとのことです。

• 大企業の既存ネットワークと繋ぐ、ハイブリッドネットワーク
• 大企業のシステムスケールに合わせた、ハイパフォーマンス
• クレジットカード情報を扱うような業務システム(PCI-DSS)
• ディザスタリカバリ

本セッションでは、それぞれの分類について、幾つものパターンをご提示頂きました。上記のスライドでは詳細までほぼ網羅されているので、以下では私の感想を併せて書きたいと思います。

ハイブリッドネットワーク

企業の既存ネットワークによくある複数拠点や複数回線、モバイル端末などで構成されたネットワークと、AWSをどのように接続するかという観点で、高い冗長性を確保するためにDirect Connect、インターネットVPN、ソフトウェアVPN、httpsトンネリングを組み合せるというもの。

例えばDirect Connectであればその中を複数のVPNを通すことで、複数のVPC・複数のAWSアカウントで1つのDirect Connectの回線をシェアしたり、Dierct Connectの冗長化としてDirect Connect2本の構成やサブ回線としてインターネットVPNを使うなど。

ネットワーク経路の冗長化はルーティングと物理回線の2つの観点から考えることが多いですが、基本的な考え方はクラウドの場合でもオンプレミスの場合も大きく変わらないと思いました。違う部分としては現時点ではVPC同士の接続が出来ないというところで、そこについては「ヘアピンDXパターン」としてオンプレミス側のルータでルーティングするという案が提示されていました。この辺はAWSならではの考慮が必要な部分ですね。

ハイパフォーマンス

こちらも大きな観点としては冗長性の確保であり、

• Self Healingパターン(EC2が落ちたら上げるだけの小さいAuto Scallingを構成する)
• Synchronized Diskパターン(データ領域用のEBSをミラーリングする)
• High Aailability Natパターン(NATインスタンスを2台構築し、片方がダウンしたらルーティングテーブルを書き換える)
• NatではなくProxyを使うパターン

などをご提示されていました。

クラウドとして特徴的なのはSelf Healingパターンですね。Auto Scallingはとても「クラウドらしい」サービスだと思います。

PCI-DSS対応システム

AWSはPCI-DSSのサービスプロバイダであり(AWS PCI DSS レベル 1 よくある質問)、インフラ部分としてはPCI-DSSを満たしているとのことで、後はシステム的にどのようにセキュリティを確保していくかの話になっていくとのこと。

例えば、

• Chained Defence-in-Depthパターン(サブネットをレイヤー毎に分けて階層とし、気密性の高い情報はアクセスが難しい奥のサブネットに配置する)
• Encrypted Log Aggregation(ログを暗号化した上で集約しておく)
• OnDemand Bastionパターン(踏み台サーバを用意し、必要なときだけ立ち上げる)

などがご提示されていました。またHigh availability IAMパターンとして「IAMアカウントをAZ毎に分けておき、IAMアカウントの設定にミスがあっても片方のAZに配置されたサーバだけ影響を受けるようにしておく」というお話もありました。

これもクラウドらしさからパターンを見ると、OnDemand Bastionパターンは「らしい」と思います。オンプレミスだと、いちいちメンテナンスで接続するたびにお客様やデータセンタの常駐エンジニアさんに「サーバ立ち上げて下さい」というのは非常に面倒ですしね。管理ポートから起動出来るようなサーバもありますのでそういう機器を入れるという手段もありますが、そのハードウェアを用意しておくコストが無駄です。

ディザスタリカバリ

ここで提示されたのは、

• Hot Standby
• Worm Standby
• Cold Standby
• Virual Cloud Storage(データだけCloudに置いておく)

といったパターンで、これら自体はオンプレミス時代からある考え方であり特別なものではありません。安価で、かつ手軽に構築が出来るようになったというのが大きな違いかも知れません。ハードウェアを買っておく必要がありませんものね。

最後に

「パターン化を繰り返すのは考え方の練習になるので是非皆さんもやってみて下さい」とのお言葉で締められました。

まとめ

クラウドデザインパターンは僕自身も参考にさせて頂いているし、エンタープライズ用途にも耐えられるように複数のパターンを組み合わせたりするのは考え方の練習としてとても面白いと思いました。また「この構成だとこのパターンは使えないよね」といったアンチクラウドデザインパターンのようなことも考えると更に勉強になるのかも知れませんね。

玉川さん、片山さん、ありがとうございました！